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REMARKS 

Claims 1-8, 10-23, 25-38, and 40-107 were pending. No claims have been 
amended, added, or cancelled. Therefore claims 1-8, 10-23, 25-38, and 40-107 remain 
pending in the application subsequent entry of the present amendment. 

35 U.S.C. § 103 Rejections in view of Lee, et al. 

In the present Office Action, claims 1-7, 15-22, 30-37, 45-52 and 59 stand 
rejected under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 6,958,992 
(hereinafter "Lee") in view of U.S. Patent No. 6,822,957 (hereinafter "Schuster"). In 
addition, dependent claims 8, 10-14, 23, 25-29, 38, 40-44, 53-54 and 56-58 stand rejected 
under 35 U.S.C § 103(a) as being unpatentable over Lee and Schuster in further view of 
U.S. Patent No. 6,577,642 (hereinafter "Fijolek"). Applicant respectfully traverses these 
rejections and requests reconsideration in view of the following comments. 

A prima facie case of obviousness of a claimed invention is not established unless 
all the claim limitations are taught or suggested by the cited prior art. Applicant 
respectfully submits not all features of the presently claimed invention are disclosed or 
suggested by the cited references, taken either alone or in combination. 

For example, claim 1 recites a method that includes: 

" receiving an identifier from the IP telephone; 
determining if a MAC ID for the IP telephone is valid; 

if the MAC ID is determined to be valid, determining if the identifier is valid; 

if the identifier is valid, assigning a range of port numbers to the IP telephone 

based on the identifier, wherein the IP telephone is operable to use at least 
a subset of the range of port numbers to send or receive IP 
communications." (emphasis added). 
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In paragraph 6 of the present Office Action, it is suggested that Lee discloses the 
above highlighted features. In particular it is stated that Lee discloses 



"receiving an identifier from the IP telephone (Fig. 3, element 320 
Service Provider ID, col. 3, lines 23 - 32); determining if the identifier 
is valid (Fig. 3, col. 3, lines 33 - 39); determining if a MAC ID for the 
IP telephone is valid (Fig. 3, col. 3, lines 33 - 39); if the MAC ID is 
determined to be valid, determining if the identifier is valid (Fig. 4, 
col. 4, lines 12 - 24, col. 6, lines 14 - 26)." 

However, Applicant disagrees. In the rejection, it is stated Lee discloses (cited 
disclosures are reproduced for convenience): 



"receiving an identifier from the IP telephone (Fig. 3, element 320 
Service Provider ID, col. 3, lines 23 - 32); 



"The IP phone 102 downloads 316 and executes the software to 
establish the IP socket to the IP phone service provider 202. The IP 
phone 102 then sends a request 318 for registration to the IP phone 
service provider 202, which includes its MAC address and set type. 
The IP phone service provider 202 then sends an Open Port request 
320 with the MAC address, the set type, and the IP address (associated 
information) to the set registration process 204 for registration of the 
IP phone 102." (Lee, col. 3, lines 33-39). 



In the above reproduced portion of the rejection, the rejection specifically calls 
out "FIG. 3, element, 320, Service Provider ID" as corresponding to the identifier 
received from the IP telephone. However, the Service Provider ID is not received from 
the IP telephone . Rather, the Service Provider ID is provided by the IP Phone Service 
Provider 202 (shown to be part of IP Phone Switch 100 in FIG. 2) in the Open Port 
request 320 to the set registration process 204. Therefore, if it is suggested the Service 
Provider ID is equivalent to the recited identifier, then Applicant submits it has not been 
shown that the reference discloses "receiving an identifier from the IP telephone" as 
recited and the suggested combination does not disclose all the features of the claim as 
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suggested. Accordingly, a prima facie case of obviousness has not been established for at 
least these reasons. 

In addition to the above, the rejection continues by suggesting Lee discloses: 
determining if the identifier is valid (Fig. 3, col. 3, lines 33 - 39)." 

The cited disclosure of Lee is reproduced below: 

"The set registration process 204 upon receiving the Open Port request 
320 checks the information against its lookup table of data shared with 
OAM 206 as shown at 322. In the present example of an unregistered 
IP phone 102, as there is no match 324 for the MAC address, the set 
registration process 204 sends a message to request a PIN 326, 328 
from the user of the IP phone 102." (Lee, col. 3, lines 33-39). 

It is first noted that the claim language is as follows: "determining if a MAC ID 
for the IP telephone is valid; if the MAC ID is determined to be valid, determining if the 
identifier is valid ." Therefore, the language "determining if the identifier is valid" 
represents part of a conditional clause - "if the MAC ID is determined to be valid, 
determining if the identifier is valid." This clarification aside, Applicant submits there is 
nothing in the above cited disclosure regarding the Service Provider ID being determined 
to be valid. Further, this disclosure of Lee nowhere mentions the Service Provider ID. In 
contrast, Lee describes the use of a lookup table to determine whether there is a match for 
a MAC address. If in this disclosure the examiner is equating the determination as to 
whether there is a match for the MAC address with the features "determining if the 
identifier is valid", then the examiner would have to equate the MAC address with the 
recited identifier. However, if the rejection seeks to equate the MAC address with the 
recited identifier, then the rejection also fails. 



31/40 



U.S. Application Serial No. 09/903,838, filed July 11, 2001 



First, it would make no sense to read the claim such that the MAC ID of Lee is 
the recited identifier. Given such an interpretation, the claim would read: 

receiving a MAC ID from the IP telephone; 

determining if the MAC ID for the IP telephone is valid; 

if the MAC ID is determined to be valid, determining if the MAC ID is valid; 

Clearly, the recited MAC ID and identifier are distinct identifiers. As already 
noted, if the Service Provider ID is equated with the recited identifier, then the rejection 
fails for at least the above reasons. On the other hand, if the rejection seeks to equate the 
MAC ID with the recited identifier, then the rejection still fails - for at least the reason 
that the claim language does not permit such an interpretation. In addition, on page 3 of 
the present Office Action, it is suggested Lee discloses: 

"determining if a MAC ID for the IP telephone is valid (Fig. 3, col. 3, 
lines 33 - 39); if the MAC ID is determined to be valid, determining if 
the identifier is valid (Fig. 4, col. 4, lines 12 - 24, col. 6, lines 14 - 
26)." 

Here the same portion of Lee is cited as was discussed above. In particular, 
determining whether there is a match in the lookup table for the MAC ID is cited as 
corresponding to the recited features "determining if a MAC ID for the IP telephone is 
valid". The rejection then continues by citing Fig. 4, col. 4, lines 12 - 24, col. 6, lines 14 - 
26 of Lee for the recited features "if the MAC ID is determined to be valid, determining 
if the identifier is valid." However, Applicant submits the features are not found in the 
cited disclosures as suggested. For example, concerning the features "if the MAC ID is 
determined to be valid, determining if the identifier is valid", the first cited portion of Lee 
(Fig. 4, col. 4, lines 12 - 24) simply describes registration of a previously registered IP 
phone 102. This description is given in the following: 
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"Once booted-up, the IP phone service provider 202 sends an Open 
Port request 320 with the MAC address, the set type, and the IP 
address (associated information) to the set registration process 204 for 
registration of the IP phone 102. 

Upon receiving the Open Port request 320, the set registration process 
204 checks the information against its lookup table of data shared with 
OAM 206 as shown at 322. In the present example, where the IP 
phone 102 has been previously registered, there is a match for the 
MAC address in the lookup table as shown at 410. To complete the 
registration, the processes 338 to 346, as previously described in 
reference to FIG. 3, are carried out." (Lee, col. 4, lines 12-24). 



In the disclosure above, Lee describes "where the IP phone 102 has been previously 
registered, there is a match for the MAC address in the lookup table." It would appear the 
examiner is equating looking for, and finding, a MAC address match in the lookup table 
with the recited features "if the MAC ID for the IP telephone is determined to be valid." 
However, even if, for the sake of argument, one were to accept such an equivalence, there 
is no disclosure of a subsequent conditional determination that an identifier sent from the 
IP telephone is valid (i.e., the features "if the MAC ID is determined to be valid, 
determining if the identifier is valid") - much less a subsequent conditional determination 
that the identifier sent from the IP telephone is valid. Rather, Lee simply states that 
processes 338 to 346 are carried out after finding the MAC address in the lookup table. 
These processes are described in the following: 



"Specifically, the set registration process 204 sends an Open Port Ack 
338 (Acknowledgement) to the IP phone service provider 202, which 
sends a registration acknowledgement 340 to the IP phone 102. Upon 
receipt of the registration acknowledgement 340, the IP phone 102 
sends a Report Set ID (set type) 342 to the OAM 206 . 

The OAM 206 and the set registration process 204 then downloads 
strings and prompts 344 desired for operation of the IP phone 102 in 
the phone system and, at 346, further updates the IP phone display 
with any information desired to be displayed by the IP phone 102." 
(Lee, col. 3 line 60 to col. 4 line 3). (emphasis added). 
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As can be seen above, acknowledgments are transferred back and forth, a Report Set ID 
342 is sent from the IP Phone 102 to the OAM 206, and then downloading of 
information, such as strings and prompts, for operation of the IP Phone 102 is performed. 
It is noted that the above nowhere discloses determining if the Report Set ID 342 is valid. 
Second, claim 1 recites "receiving an identifier from the IP telephone" prior to the recited 
features "if the MAC ID is determined to be valid, determining if the identifier is valid." 
In fact, the present Office Action uses the separate prior description of the registration of 
an unregistered IP phone 102 to suggest that Lee discloses the features "receiving an 
identifier from the IP telephone". Therefore, by suggesting Lee discloses the features of 
claim 1 in the descriptions of two separate registrations, it is not clear in the Examiner's 
comments as to what value is being suggested as being the identifier in Lee that is sent by 
the IP telephone. As shown above, in the description of the registration of a previously 
registered IP telephone, an identifier sent by the IP telephone is the Report Set ID 342 
which is not disclosed anywhere to be determined to be valid at all - let alone determined 
to be valid "if the MAC ID is determined to be valid" as recited in the claim. For 
example, in the description of the registration of an unregistered IP telephone 102 in Lee, 
an identifier sent by the IP telephone in a request 3 1 8 is the MAC address, and not the 
Report Set ID 342, as disclosed by Lee in the following: 

"The IP phone 102 downloads 316 and executes the software to 
establish the IP socket to the IP phone service provider 202. The IP 
phone 102 then sends a request 318 for registration to the IP phone 
service provider 202, which includes its MAC address and set type . 
The IP phone service provider 202 then sends an Open Port request 
320 with the MAC address, the set type, and the IP address (associated 
information) to the set registration process 204 for registration of the 
IP phone 102." (Lee, col. 3 lines 23-32) (emphasis added) 

Still further, regardless of whether the identifier received from the IP telephone in 
Lee is the MAC address or the Report Set ID 342, neither value is conditionally 
determined to be valid as recited wherein the claim reads, "if the MAC ID is determined 
to be valid, determining if the identifier is valid." Therefore, Lee nowhere discloses at 
least the features "if the MAC ID is determined to be valid, determining if the identifier is 
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valid." For at least the above reasons, claim 1 is patently distinct from the cited 
references taken alone or in combination. 



In addition to the above, the rejection further cites column 6 of Lee is support of 
the rejection. In particular, it is stated that Lee discloses: 

"determining if a MAC ID for the IP telephone is valid (Fig. 3, col. 3, 
lines 33 - 39); if the MAC ID is determined to be valid, determining if 
the identifier is valid (Fig. 4, col. 4, lines 12 - 24, col. 6, lines 14 - 
26)." 



Column 6, lines 14-26 of Lee are as follows: 



"A number of further alternatives are described below. A user may 
specify a DN, at will, to associate with a PIN, which as previously 
noted has a separate access code. Provided the specified DN is not 
being used, the DN can be associated with the user. A user may be 
assigned several PINs for the same directory number where each PIN 
has a different purpose, for example, a PIN for an unsecured IP phone, 
which expires after one use, and another PIN for a different directory 
number. A user may have a number of different directory numbers 
associated with one IP phone. A PIN may also associate a DN to an IP 
phone temporarily, such as 24 hours, for a user to receive calls for the 
DN wherever he or she may be temporarily located." 



However, Applicant finds nothing in the above disclosure to support the rejection 
of the features "if the MAC ID is determined to be valid, determining if the identifier is 
valid." This disclosure simply describes the association of PINs to DNs. 

For at least the above reasons, Applicant submits the combination of references 
do not disclose or suggest all the features of claim 1 . Accordingly, a prima facie case of 
obviousness has not been established. As independent claims 3 1 , and 46 include features 
similar to claim 1, claims 31, and 46 are patentably distinguished from the cited 
references for at least reasons similar to those discussed above. Claim 16 is addressed on 
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page 10 of the present Office Action in a manner similar to that of claims 1,31 and 46. 
As independent claim 16 includes features similar to claim 1, claim 16 is patentably 
distinguished from the cited references for at least reasons similar to those discussed 
above. Each of the dependent claims are patentably distinguishable for at least the 
reasons give above in relation to the independent claims upon which they depend. 

35 U.S.C. § 102 Rejections and § 103 Rejections in view of Edholm, et al. 

Claims 60, 68, 76, 100, 81, 105, 84, and 92 stand rejected under 35 U.S.C. § 
102(e) as being anticipated by U.S. Patent No. 6,772,210 (hereinafter "Edholm"). In 
addition, claims 61-66, 69-74, 77-80, 82, 85-90, 93-98, 101-104, and 106 stand rejected 
under 35 U.S.C. § 103(a) as being unpatentable over Edholm in view of U.S. Patent 
Publication No. 2002/0093915 (hereinafter "Larson"). Further, claims 67, 75, 83, 91, 99 
and 107 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over Edholm in 
view of Larson, and in further view of U.S. Patent No. 6,882,957. Applicant respectfully 
traverses these rejections and requests reconsideration in view of the following 
comments. 

Anticipation requires the presence in a single prior art reference disclosure of each 
and every element of the claimed invention, arranged as in the claim. Lindemann 
Maschinenfabrik GmbH v. American Hoist & Derrick Co., 221 USPQ 481, 485 (Fed. Cir. 
1984). The identical invention must be shown in as complete detail as is contained in the 
claims. Richardson v. Suzuki Motor Co., 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 
Applicant submits each of independent claims 60, 68, 76, 100, 81, 105, 84, and 92 recite 
features neither disclosed nor suggested by Edholm. 

For example, claim 60 recites a system including a service gateway which is 
configured to: 
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"receive the first data packet with the first private IP address; and 

perform network address translation (NAT) on the first data packet with a 

second private IP address, the second private IP address being assigned 

by a service provider." 

In the rejection, it is suggested that Edholm discloses: 

"[T]he SG is configured to: receive the first data packet with the first 
private IP address (Fig. 4, element 404, col. 6, lines 57 - 60); and 
perform network address translation (NAT) on the first data packet 
with a second private IP address, the second private IP address being 
assigned by a service provider (col. 4, lines 56 - 66, col. 6, line 67, col. 
7, lines 1-12." (Office Action, pages 16-17). 



However, Applicant disagrees and submits Edholm does not disclose or suggest at 
least the features "perform network address translation (NAT) on the first data packet 
with a second private IP address, the second private IP address being assigned by a 
service provider." In support of the rejection, the following disclosures of Edholm are 
cited: 



"The calling VoIP device typically obtains the (public) network 
address or address/port number pair for the called VoIP device directly 
or indirectly from the gateway 106. Specifically, a request may be sent 
to the gateway 106 requesting the (public) network address for the 
called VoIP device. The request may be sent by the gatekeeper 1 12, in 
which case the gatekeeper 112 obtains the (public) network address for 
the called VoIP device from the gateway 106 and provides the (public) 
network address for the called VoIP device to the calling VoIP device, 
typically along with the gateway address." (Edholm, col. 4, lines 56- 
66). 

The logic selects a public address for the private VoIP device 110 from 
an address pool, in block 412, and optionally selects a port number 
(socket) for the private VoIP device 110, in block 414. The logic 
installs an address translation entry in the address mapping database 
mapping the private address of the private VoIP device 110 to the 
public address or public address/port number pair for the private VoIP 
device 110, in block 416. The logic determines the public address for 
the public VoIP device 102, in block 418, for example, based upon 



37/40 



U.S. Application Serial No. 09/903,838, filed July 11, 2001 



address mapping information contained in an address mapping 
database. The logic returns the public address for the public VoIP 
device, in block 420. The logic 400 terminates in block 499. (Edholm, 
col. 6, line 67 - col. 7, line 12). 



As seen from the above, there is no disclosure of performing network address 
translation with a second private IP address. In contrast, the disclosure clearly describes 
"mapping the private address of the private VoIP device 110 to the public address . . .." 
Therefore, even were one to assume the disclosed private address and public address 
were a private IP address and public IP address (which Applicant does not admit), there is 
no disclosure of a translation with a second private IP address as recited. Accordingly, 
Applicant submits claim 60 is not anticipated by Edholm and withdrawal of the rejection 
is requested. Additionally, each of independent claims 68, 76, and 81 include features 
similar to that of claim 60 and are patentably distinguishable for at least reasons similar 
to those discussed above. Applicant notes that in the rejection on page 17, claim 76 is 
grouped with claim 100, and claim 81 is grouped with claim 105, even though these 
claims have dissimilar features. Applicant assumes this to be a typographical error. 
Nevertheless, the above traversals remain for the reasons given. 

In addition, Applicant does not agree that Edholm discloses the features "receive 
the first data packet with the first private IP address" as recited in claim 60. In contrast, 
Edholm discloses: 



"FIG. 4 is a logic flow diagram showing exemplary logic 400 for 
establishing the VoIP connection by the gateway 106 when the VoIP 
connection is initiated by the private VoIP device 110. Beginning at 
block 402, and upon receiving a request for a VoIP connection 
initiated by the private VoIP device 110, in block 404, the logic 
determines the called VoIP device, in block 406, for example, based 
upon the phone number of the called VoIP device. Upon determining 
that the called VoIP device is the public VoIP device 102, in block 
408, the logic determines the private address of the private VoIP 
device 110, in block 410, for example, based upon address mapping 
information contained in an address mapping database." (Edholm, col. 
6, lines 55-67). 
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In the above disclosure it can be seen that a request for a VoIP connection 
initiated by the private VoIP device 110 is received. Subsequent to determining that the 
called device is a public VoIP device, "the logic determines the private address of the 
private VoIP device 110, in block 410, for example, based upon address mapping 
information contained in an address mapping database." This clearly suggests the private 
address of the private VoIP device is not received from the VoIP device. Rather, the 
private address is determined via an address mapping database. Accordingly, Edholm 
does not anticipate claim 60 for at least these further reasons. Each of claims 68, 76, and 
81 are similarly distinguishable for at least these further reasons. Similar to claims 60, 
68, 76 and 81, each of independent claims 84, 92, 100 and 105 recite features regarding 
conveyance or receipt of a data packet from an IP device with a private address. 
Accordingly, Edholm does not anticipate claims 84, 92, 100, and 105 for at least these 
reasons. 

As each of the dependent claims includes the features of the independent claims 
upon which they depend, each of the dependent claim are patentably distinguishable for 
at least the reasons give above in relation to the independent claims upon which they 
depend. Accordingly, while the dependent claims recite additional patentably 
distinguishable features, further discussion of these claims is not believed necessary at 
this time. 
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CONCLUSION 



Applicant submits the application is in condition for allowance, and an early 
notice to that effect is requested. 



If any extensions of time (under 37 C.F.R. § 1.136) are necessary to prevent the 
above referenced application(s) from becoming abandoned, Applicant(s) hereby petition 
for such extensions. If any fees are due, the Commissioner is authorized to charge said 
fees to Meyertons, Hood, Kivlin, Kowert & Goetzel PC Deposit Account No. 50- 
1505/5686-00300/RDR. 



Respectfully submitted, 



/ Rory D. Rankin / 

Rory D. Rankin 
Reg. No. 47,884 

ATTORNEY FOR APPLICANT(S) 



Meyertons, Hood, Kivlin, 
Kowert & Goetzel PC 
P.O. Box 398 
Austin, TX 78767-0398 
Phone: (512) 853-8800 
Date: March 23, 2009 



40/40 



